DESIGN: Answer who this is for

diff --git a/DESIGN b/DESIGN
index 17cc01589dd8540d85c0f93f52b708500dbaa5a9..f8f65e6c91ae0b479bbbf1aeea607e91af6e3f07 100644 (file)
--- a/DESIGN
+++ b/DESIGN
@@ -9,8 +9,9 @@ hacktree-root-manager
 
 == Problem statement ==
 
-Hacking on the core operating system is painful.  We want a system
-that matches these requirements:
+Hacking on the core operating system is painful - this includes most
+of GNOME from upower and NetworkManager up to gnome-shell.  I want a
+system that matches these requirements:
 
 0) Does not disturb your existing OS
 1) Is not terribly slow to use
@@ -31,6 +32,29 @@ jhbuild + OS packages:
   this means you can't build NetworkManager, and thus are permanently
   stuck on whatever the distro provides.
 
+== Who is hacktree for? ==
+
+First - operating system developers and testers.  I specifically keep
+a few people in mind - Dan Williams and Eric Anholt, as well as myself
+obviously.  For Eric Anholt, a key use case for him is being able to
+try out the latest gnome-shell, and combine it with his work on Mesa,
+and see how it works/performs - while retaining the ability to roll
+back if one or both breaks.
+
+The rollback concept is absolutely key for shipping anything to
+enthusiasts or knowledable testers.  With a system like this, a tester
+can easily perform a local rollback - something just not well
+supported by dpkg/rpm.  (Why not Conary?  AIUI Conary is targeted at
+individual roots, so while you could roll back a given root, it would
+use significantly more disk space than hacktree)
+
+Also, distributing operating system trees (instead of packages) gives
+us a sane place to perform automated QA **before** we ship it to
+testers.  We should never be wasting these people's time.
+
+Even better, this system would allow testers to bisect across
+operating system builds efficiently.
+
 == The core idea ==
 
 chroots are the original lightweight "virtualization".  Let's use